Frontend API lüüs: GraphQL Federation ja Schema Stitching

Kaasaegse veebirakenduste arenduse maailmas võib mitmest allikast pärit andmete haldamine olla märkimisväärne väljakutse. Rakenduste keerukuse kasvades ja mikroteenuste arhitektuuride kasutuselevõtuga muutub ühtse ja tõhusa andmetele juurdepääsu viisi vajadus esmatähtsaks. Frontend API lüüs toimib kliendirakenduste jaoks keskse sisenemispunktina, koondades andmeid erinevatest taustateenustest ja pakkudes sujuvamat kogemust nii arendajatele kui ka lõppkasutajatele. See blogipostitus uurib kahte võimsat tehnikat Frontend API lüüsi ehitamiseks: GraphQL Federation ja Schema Stitching.

Mis on Frontend API lüüs?

Frontend API lüüs on arhitektuuriline muster, kus spetsiaalne server toimib vahendajana frontend klientide (nt veebibrauserid, mobiilirakendused) ja mitmete taustateenuste vahel. See lihtsustab andmete pärimist järgmiselt:

• Andmete koondamine: Andmete kombineerimine mitmest allikast ühte vastusesse.
• Andmete teisendamine: Andmevormingute kohandamine vastavalt frontendi vajadustele.
• Keerukuse abstraheerimine: Taustateenuste keerukuse peitmine kliendi eest.
• Turvalisuse tagamine: Autentimis- ja autoriseerimispoliitikate rakendamine.
• Jõudluse optimeerimine: Sageli kasutatavate andmete vahemällu salvestamine ja võrgupäringute arvu vähendamine.

Põhimõtteliselt rakendab see Backend for Frontend (BFF) mustrit laiaulatuslikult ja annab frontend meeskondadele rohkem kontrolli nende tarbitavate API-de üle. Suuremates organisatsioonides võib see, kui frontend haldab ja kureerib oma API-sid, viia kiirema tarneni ja vähendada sõltuvust taustameeskondadest.

Miks kasutada GraphQL-i Frontend API lüüsi jaoks?

GraphQL on päringukeel API-de jaoks ja käitusaeg nende päringute täitmiseks olemasolevate andmetega. See pakub mitmeid eeliseid traditsiooniliste REST API-de ees, muutes selle sobivaks Frontend API lüüside ehitamiseks:

• Tõhus andmete pärimine: Kliendid küsivad ainult neid andmeid, mida nad vajavad, vähendades üleliigset andmete pärimist ja parandades jõudlust.
• Tugev tüüpimine: GraphQL skeemid määratlevad andmete struktuuri, võimaldades paremaid tööriistu ja valideerimist.
• Introspektsioon: Kliendid saavad skeemi introspektsiooni kaudu avastada saadaolevaid andmeid ja operatsioone.
• Reaalajas võimalused: GraphQL tellimused (subscriptions) võimaldavad reaalajas andmete uuendamist.

GraphQL-i võimendades saab Frontend API lüüs pakkuda paindlikku, tõhusat ja arendajasõbralikku liidest mitmest taustateenusest andmete pärimiseks. See on teravas kontrastis traditsiooniliste lähenemistega, mis kasutavad mitut REST-i lõpp-punkti, millest igaüht tuleb eraldi pärida ja mis tagastavad sageli rohkem andmeid kui vaja.

GraphQL Federation: Hajutatud lähenemine

Mis on GraphQL Federation?

GraphQL Federation on võimas tehnika hajutatud GraphQL API ehitamiseks, komponeerides mitu GraphQL teenust (nimetatakse "alamgraafideks") üheks ühtseks skeemiks. Iga alamgraaf vastutab konkreetse domeeni või andmeallika eest ja Federationi lüüs orkestreerib päringuid nende alamgraafide vahel.

Põhikontseptsioon keerleb supergraafi ümber, mis on üks ühtne GraphQL skeem, mis esindab kogu API-d. See supergraaf ehitatakse väiksemate GraphQL skeemide, nn alamgraafide, komponeerimisel, millest igaüks esindab konkreetset mikroteenust või andmeallikat. Federationi lüüsi ülesanne on suunata sissetulevad GraphQL päringud sobivatele alamgraafidele ja kombineerida tulemused üheks vastuseks.

Kuidas GraphQL Federation töötab

1. Alamgraafi määratlemine: Iga mikroteenus eksponeerib GraphQL API (alamgraafi), mis määratleb oma andmed ja operatsioonid. Need skeemid sisaldavad direktiive, mis ütlevad Federationi lüüsile, kuidas tüüpe ja välju lahendada. Peamised direktiivid on `@key`, `@external` ja `@requires`.
2. Supergraafi komponeerimine: Federationi lüüs (nt Apollo Gateway) hangib skeemid igast alamgraafist ja komponeerib need üheks ühtseks skeemiks (supergraafiks). See protsess hõlmab tüübi- ja väljakonfliktide lahendamist ning seoste loomist erinevate alamgraafide tüüpide vahel.
3. Päringu planeerimine ja täitmine: Kui klient saadab GraphQL päringu lüüsile, analüüsib lüüs päringut ja määrab, milliseid alamgraafe on vaja päringu täitmiseks pärida. Seejärel jaotab see päringu sobivatele alamgraafidele, kogub tulemused ja kombineerib need üheks vastuseks, mis tagastatakse kliendile.

Näide: E-kaubanduse platvorm GraphQL Federationiga

Kujutage ette e-kaubanduse platvormi, millel on eraldi mikroteenused toodete, klientide ja tellimuste jaoks.

• Toodete alamgraaf: Haldab tooteinfot (nimi, kirjeldus, hind jne).
• Klientide alamgraaf: Haldab kliendiandmeid (nimi, aadress, e-post jne).
• Tellimuste alamgraaf: Haldab tellimuste infot (tellimuse ID, kliendi ID, toote ID-d, kogusumma jne).

Iga alamgraaf eksponeerib GraphQL API ja Federationi lüüs komponeerib need API-d üheks supergraafiks. Klient saab seejärel pärida supergraafi, et saada ühe päringuga teavet toodete, klientide ja tellimuste kohta.

Näiteks päring kliendi nime ja tema tellimuste ajaloo hankimiseks võiks välja näha selline:

query GetCustomerAndOrders($customerId: ID!) {
  customer(id: $customerId) {
    id
    name
    orders {
      id
      orderDate
      totalAmount
    }
  }
}

Federationi lüüs suunaks selle päringu klientide ja tellimuste alamgraafidesse, hangiks vajalikud andmed ja kombineeriks need üheks vastuseks.

GraphQL Federationi eelised

• Lihtsustatud andmetele juurdepääs: Kliendid suhtlevad ühe GraphQL lõpp-punktiga, sõltumata aluseks olevatest andmeallikatest.
• Parem jõudlus: Andmete pärimine on optimeeritud, hankides igast alamgraafist ainult vajalikud andmed.
• Suurem skaleeritavus: Iga alamgraafi saab skaleerida iseseisvalt, mis võimaldab paremat ressursside kasutamist.
• Detsentraliseeritud arendus: Meeskonnad saavad alamgraafe iseseisvalt arendada ja juurutada, edendades agiilsust ja innovatsiooni.
• Skeemi haldus: Federationi lüüs tagab skeemi järjepidevuse ja ühilduvuse alamgraafide vahel.

Tööriistad GraphQL Federationi jaoks

• Apollo Federation: Populaarne avatud lähtekoodiga GraphQL Federationi implementatsioon, mis pakub lüüsi, skeemiregistrit ja tööriistu födereeritud GraphQL API-de ehitamiseks ja haldamiseks. Apollo Federation on tuntud oma skaleeritavuse ja robustse veakäsitluse poolest.
• GraphQL Hive: See tööriist pakub skeemiregistrit ja haldust GraphQL födereeritud teenustele, pakkudes funktsioone nagu muudatuste tuvastamine, kasutusanalüüs ja skeemikontrollid. See parandab supergraafi nähtavust ja kontrolli selle üle.

Schema Stitching: Alternatiivne lähenemine

Mis on Schema Stitching?

Schema Stitching on teine tehnika mitme GraphQL skeemi kombineerimiseks üheks ühtseks skeemiks. Erinevalt Federationist hõlmab Schema Stitching tavaliselt manuaalsemat protsessi, kus määratletakse, kuidas erinevate skeemide tüübid ja väljad on omavahel ühendatud. Kuigi Federationit peetakse kaasaegsemaks ja robustsemaks lahenduseks, võib Schema Stitching olla elujõuline valik lihtsamate kasutusjuhtude jaoks või olemasolevatest GraphQL API-dest migreerumisel.

Kuidas Schema Stitching töötab

1. Skeemi määratlemine: Iga mikroteenus eksponeerib GraphQL API omaenda skeemiga.
2. Stitchingu loogika: Stitching-kiht (sageli implementeeritud kasutades teeke nagu GraphQL Tools) määratleb, kuidas erinevate skeemide tüübid ja väljad on omavahel ühendatud. See hõlmab resolver-funktsioonide kirjutamist, mis hangivad andmeid aluseks olevatest teenustest ja kaardistavad need ühtsesse skeemi.
3. Ühtne skeem: Stitching-kiht kombineerib individuaalsed skeemid üheks ühtseks skeemiks, mis eksponeeritakse kliendile.

Näide: Toodete ja arvustuste ühendamine (stitching)

Kujutage ette kahte eraldi GraphQL teenust: üks toodete ja teine arvustuste jaoks.

• Toodete teenus: Pakub teavet toodete kohta (ID, nimi, kirjeldus, hind).
• Arvustuste teenus: Pakub arvustusi toodete kohta (ID, toote ID, hinnang, kommentaar).

Kasutades Schema Stitchingut, saate luua ühtse skeemi, mis võimaldab klientidel hankida tooteinfot ja arvustusi ühe päringuga.

Te peaksite määratlema stitching-kihis resolver-funktsiooni, mis hangib antud toote ID jaoks arvustused arvustuste teenusest ja lisab need ühtses skeemis olevale Product-tüübile.

// Näide (kontseptuaalne): Stitching loogika kasutades GraphQL Toolsi
const { stitchSchemas } = require('@graphql-tools/stitch');

const productsSchema = ... // Määratle oma toodete skeem
const reviewsSchema = ... // Määratle oma arvustuste skeem

const stitchedSchema = stitchSchemas({
  subschemas: [
    {
      schema: productsSchema,
    },
    {
      schema: reviewsSchema,
      transforms: [
        {
          transformSchema: (schema) => schema,
          transformRequest: (originalRequest) => {
            return originalRequest;
          },
          transformResult: (originalResult) => {
            return originalResult;
          }
        }
      ],
    },
  ],
  typeDefs: `
    extend type Product {
      reviews: [Review]
    }
  `,
  resolvers: {
    Product: {
      reviews: {
        resolve: (product, args, context, info) => {
          // Hangi toote arvustused arvustuste teenusest
          return fetchReviewsForProduct(product.id);
        },
      },
    },
  },
});

See näide demonstreerib skeemide kokkuõmblemise põhikontseptsiooni. Pange tähele vajadust kohandatud resolverite järele `reviews` välja hankimiseks. See täiendav koodikirjutamise lisakulu iga seose jaoks võib muuta arendusprotsessi aeglasemaks kui Federationi kasutamine.

Schema Stitchingu eelised

• Ühtne API: Kliendid pääsevad juurde ühele GraphQL lõpp-punktile, lihtsustades andmetele juurdepääsu.
• Järkjärguline kasutuselevõtt: Schema Stitchingut saab rakendada järk-järgult, võimaldades teil samm-sammult üle minna ühtsele API-le.
• Paindlikkus: Schema Stitching pakub rohkem kontrolli selle üle, kuidas skeeme kombineeritakse, võimaldades teil kohandada stitching-loogikat vastavalt konkreetsetele vajadustele.

Schema Stitchingu puudused

• Käsitsi seadistamine: Schema Stitching nõuab stitching-loogika käsitsi seadistamist, mis võib olla keeruline ja aeganõudev.
• Jõudluse lisakulu: Resolver-funktsioonid võivad tekitada jõudluse lisakulu, eriti kui need hõlmavad keerulisi andmete teisendusi.
• Piiratud skaleeritavus: Schema Stitchingut võib olla keerulisem skaleerida kui Federationit, kuna stitching-loogika on tavaliselt tsentraliseeritud.
• Skeemi omandiõigus: Võib tekitada ebaselgust skeemi omandiõiguse osas, eriti kui erinevad meeskonnad haldavad ühendatud teenuseid.

Tööriistad Schema Stitchingu jaoks

• GraphQL Tools: Populaarne teek GraphQL skeemide ehitamiseks ja manipuleerimiseks, sealhulgas Schema Stitchingu toega.
• GraphQL Mesh: GraphQL Mesh võimaldab teil kasutada GraphQL päringukeelt andmete pärimiseks erinevatest allikatest nagu REST API-d, andmebaasid ja gRPC. See suudab need API-d ühendada ühtseks GraphQL skeemiks.

GraphQL Federation vs. Schema Stitching: Võrdlus

Nii GraphQL Federation kui ka Schema Stitching pakuvad viise mitme GraphQL skeemi kombineerimiseks üheks API-ks, kuid need erinevad oma lähenemisviisi ja võimekuse poolest.

Omadus	GraphQL Federation	Schema Stitching
Lähenemine	Hajutatud, automatiseeritud komponeerimine	Tsentraliseeritud, käsitsi seadistamine
Keerukus	Madalam keerukus hooldamisel ja skaleerimisel	Kõrgem keerukus käsitsi resolver-loogika tõttu
Skaleeritavus	Mõeldud suurtele, hajutatud süsteemidele	Vähem skaleeritav, tavaliselt kasutatakse väiksemate rakenduste jaoks
Skeemi haldus	Sisseehitatud skeemi haldus ja valideerimine	Nõuab käsitsi skeemi haldamist ja koordineerimist
Tööriistad	Tugev tööriistade ja teekide ökosüsteem (nt Apollo Federation)	Nõuab rohkem kohandatud tööriistu ja seadistamist
Kasutusjuhud	Mikroteenuste arhitektuurid, suuremahulised API-d, detsentraliseeritud arendus	Väiksemad rakendused, järkjärguline migratsioon, spetsiifilised kohandamisnõuded

Millal kasutada GraphQL Federationi: Valige Federation, kui teil on keeruline mikroteenuste arhitektuur, peate oma API-d skaleerima ja soovite anda iseseisvatele meeskondadele võimaluse hallata oma alamgraafe. See lihtsustab ka skeemi haldamist ja valitsemist.

Millal kasutada Schema Stitchingut: Kaaluge Schema Stitchingut, kui teil on lihtsam API, vajate rohkem kontrolli stitching-loogika üle või migreerute olemasolevatest GraphQL API-dest. Olge siiski teadlik potentsiaalsetest keerukustest ja skaleeritavuse piirangutest.

Autentimise ja autoriseerimise rakendamine

Sõltumata sellest, kas valite GraphQL Federationi või Schema Stitchingu, on autentimise ja autoriseerimise rakendamine teie Frontend API lüüsi turvamiseks ülioluline. Saate kasutada mitmeid lähenemisviise:

• Lüüsi taseme autentimine: API lüüs tegeleb autentimise ja autoriseerimisega enne päringute suunamist taustateenustele. See lähenemine tsentraliseerib turvalisuse loogika ja lihtsustab taustateenuseid. Levinud meetodid on JWT (JSON Web Token) valideerimine ja OAuth 2.0.
• Teenuse taseme autentimine: Iga taustateenus tegeleb oma autentimise ja autoriseerimisega. See lähenemine pakub peenemat kontrolli turvalisuse üle, kuid seda võib olla keerulisem hallata.
• Hübriidne lähenemine: Kombinatsioon lüüsi taseme ja teenuse taseme autentimisest. Lüüs tegeleb esmase autentimisega ja taustateenused teostavad peenemaid autoriseerimiskontrolle.

Näide: JWT autentimine Apollo Federationiga

Apollo Federationiga saate konfigureerida lüüsi valideerima päringu päistes sisalduvaid JWT-märke. Lüüs saab seejärel edastada märgist eraldatud kasutajateabe alamgraafidele, mis saavad seda teavet kasutada autoriseerimiseks.

// Näide (kontseptuaalne): Apollo Gateway seadistus JWT valideerimisega
const { ApolloGateway } = require('@apollo/gateway');

const gateway = new ApolloGateway({
  serviceList: [
    // ... teie alamgraafide konfiguratsioonid
  ],
  buildService: ({ name, url }) => {
    return new MyCustomService({
      name,  // Alamgraafi nimi
      url,   // Alamgraafi URL
    });
  },
});

class MyCustomService extends RemoteGraphQLDataSource {
  willSendRequest({ request, context }) {
    // Hangi kasutaja kontekstist
    const user = context.user;

    // Lisa kasutaja ID päringu päistesse
    if (user) {
      request.http.headers.set('user-id', user.id);
    }
  }
}

Selles näites luuakse kohandatud teenus, et muuta väljaminevaid päringuid, lisades neile JWT-st tuletatud kasutaja ID. Allavoolu teenused saavad seejärel seda ID-d kasutada autoriseerimiskontrollideks.

Vahemälustrateegiad jõudluse optimeerimiseks

Vahemällu salvestamine on Frontend API lüüsi jõudluse parandamiseks hädavajalik. Salvestades sageli kasutatavaid andmeid vahemällu, saate vähendada koormust taustateenustele ja parandada klientide vastuseaegu. Siin on mõned vahemälustrateegiad:

• HTTP vahemälu: Kasutage HTTP vahemälumehhanisme (nt `Cache-Control` päised), et salvestada vastuseid brauseris ja vahepealsetes puhverserverites.
• Mälusisene vahemälu: Kasutage mälusiseseid vahemälusid (nt Redis, Memcached), et salvestada sageli kasutatavaid andmeid lüüsil.
• CDN vahemälu: Kasutage sisuedastusvõrke (CDN), et salvestada staatilisi varasid ja API vastuseid kliendile lähemale.
• GraphQL päringute vahemällu salvestamine: Salvestage GraphQL päringute tulemused vahemällu nende päringustringi ja muutujate alusel. See võib olla eriti tõhus sageli täidetavate päringute puhul. Apollo Server pakub sisseehitatud tuge päringute vahemällu salvestamiseks.

Vahemälu rakendamisel kaaluge vahemälu tühistamise strateegiaid, et tagada klientidele ajakohaste andmete saamine. Levinud strateegiad on järgmised:

• Ajapõhine aegumine: Määrake vahemällu salvestatud andmetele kindel aegumisaeg.
• Sündmuspõhine tühistamine: Tühistage vahemälu, kui andmed taustateenustes muutuvad. Seda saab saavutada veebihaakide (webhooks) või sõnumijärjekordade abil.

Monitooring ja jälgitavus

Monitooring ja jälgitavus on teie Frontend API lüüsi tervise ja jõudluse tagamiseks kriitilise tähtsusega. Rakendage põhjalik monitooring, et jälgida peamisi mõõdikuid, näiteks:

• Päringu latentsus: Aeg, mis kulub päringu töötlemiseks.
• Veamäärad: Protsent päringutest, mis lõppevad vigadega.
• Läbilaskevõime: Ajaühikus töödeldud päringute arv.
• Ressursside kasutus: Lüüsi ja taustateenuste protsessori, mälu ja võrgu kasutus.

Kasutage jälitamist (tracing), et jälgida päringuid nende liikumisel läbi süsteemi, tuvastades kitsaskohti ja jõudlusprobleeme. Logimine pakub väärtuslikku teavet lüüsi ja taustateenuste käitumise kohta.

Monitooringu ja jälgitavuse tööriistad hõlmavad:

• Prometheus: Avatud lähtekoodiga monitooringu- ja hoiatussüsteem.
• Grafana: Andmete visualiseerimise ja monitooringu tööriist.
• Jaeger: Avatud lähtekoodiga hajutatud jälitamise süsteem.
• Datadog: Monitooringu- ja turvaplatvorm pilverakendustele.
• New Relic: Digitaalse intelligentsuse platvorm tarkvara jõudluse monitoorimiseks ja parandamiseks.

Rakendades robustset monitooringut ja jälgitavust, saate proaktiivselt tuvastada ja lahendada probleeme, tagades oma Frontend API lüüsi töökindluse ja jõudluse.

Kokkuvõte

GraphQL Federationi või Schema Stitchinguga ehitatud Frontend API lüüs võib oluliselt lihtsustada andmetele juurdepääsu, parandada jõudlust ja täiustada arendajakogemust kaasaegsetes veebirakendustes. GraphQL Federation pakub võimsat ja skaleeritavat lahendust hajutatud GraphQL API-de komponeerimiseks, samas kui Schema Stitching pakub paindlikumat lähenemist olemasolevate skeemide kombineerimiseks. Hoolikalt kaaludes oma rakenduse spetsiifilisi nõudeid ja nende tehnikate vahelisi kompromisse, saate valida parima lähenemisviisi robustse ja tõhusa Frontend API lüüsi ehitamiseks.

Ärge unustage rakendada nõuetekohast autentimist ja autoriseerimist, vahemälustrateegiaid ning monitooringut ja jälgitavust, et tagada oma lüüsi turvalisus, jõudlus ja töökindlus. Neid parimaid tavasid omaks võttes saate avada GraphQL-i täieliku potentsiaali ja ehitada kaasaegseid veebirakendusi, mis pakuvad erakordseid kasutajakogemusi.